Selenium is one of the most widely used open-source tools for automating web browsers. Its history began in 2004 at ThoughtWorks in Chicago, where Jason Huggins created an internal automation tool to test a web-based Time and Expenses application. Over the years, Selenium evolved from a small JavaScript-based testing tool into a complete browser automation ecosystem centered around Selenium WebDriver.
The evolution of Selenium involved several important milestones, including Selenium Core, Selenium Remote Control (RC), Selenium IDE, Selenium Grid, WebDriver, Selenium 2, Selenium 3, and Selenium 4. Each stage addressed limitations of earlier approaches and introduced better ways to automate modern web applications.
For professional Selenium training, you can explore the JustAcademy Selenium Training course and Register for Selenium Course Demo.
The history of Selenium starts in 2004 at ThoughtWorks in Chicago. Jason Huggins was working on testing an internal web application and found that repeatedly performing browser-based tests manually was inefficient.
To solve this problem, he created a JavaScript-based automation tool that could interact with web pages automatically. The tool was initially known as JavaScriptTestRunner.
The early idea behind Selenium was simple: instead of manually opening a browser, entering information, clicking buttons, and checking results every time an application changed, the tester could write automated instructions and execute them repeatedly.
Manual Testing
|
v
Open Browser
|
v
Enter Data
|
v
Click Buttons
|
v
Verify Result
|
v
Repeat Again
Selenium introduced the possibility of automating this repetitive process.
| Year | Milestone | Importance |
|---|---|---|
| 2004 | JavaScriptTestRunner | Jason Huggins created the initial browser automation tool at ThoughtWorks. |
| 2004 | Selenium Core | The original JavaScript-based automation technology evolved into Selenium Core. |
| 2005 | Selenium Remote Control | The Selenium server-based approach evolved into Selenium RC. |
| 2006 | Selenium IDE | Shinya Kasatani developed a Firefox-based IDE capable of recording and replaying browser actions. |
| 2007 | WebDriver | Simon Stewart worked on WebDriver, using browser-specific automation mechanisms. |
| 2008 | Selenium Grid | Grid enabled Selenium tests to run across remote machines and browsers. |
| 2009 | Selenium and WebDriver Merger | The Selenium and WebDriver projects moved toward a combined future. |
| 2011 onward | Selenium 2 | WebDriver became the central automation API, while Selenium RC was retained for compatibility during the transition. |
| 2016 | Selenium 3 | Selenium continued its transition toward WebDriver-based browser automation. |
| 2021 | Selenium 4 | Selenium 4 introduced the modern WebDriver architecture and W3C WebDriver standard alignment. |
The Selenium story officially starts in 2004 at ThoughtWorks in Chicago.
Jason Huggins was testing an internal Time and Expenses application built using Python and Plone. The repetitive nature of browser testing motivated him to create an automation solution.
The initial system was called JavaScriptTestRunner. It used JavaScript to interact with web pages and automate browser-based testing.
JavaScript was already capable of interacting with elements inside web pages. This made it possible to automate actions such as:
The first version of Selenium was not initially called Selenium. It was known as JavaScriptTestRunner.
The purpose of JavaScriptTestRunner was to automate browser interactions and make repetitive functional testing easier.
Test Script
|
v
JavaScriptTestRunner
|
v
Web Browser
|
v
Web Application
|
v
Test Result
The tool demonstrated that browser-based testing could be automated instead of repeatedly performed manually.
As the tool was demonstrated to other ThoughtWorks employees, people became interested in its potential as a reusable testing framework.
The project started attracting contributors and users who saw value in automatically interacting with web applications.
The technology eventually became known as Selenium.
The name Selenium became associated with a humorous reference to the competing testing product Mercury. Selenium is a chemical element, and the name was used as a joke involving mercury poisoning and selenium supplements. The name eventually remained with the project.
After the initial development, discussions began about making Selenium available as an open-source project.
Open sourcing Selenium allowed developers and testers outside ThoughtWorks to use, improve, extend, and contribute to the project.
One of the important technical challenges in the early Selenium architecture was the browser's same-origin policy.
JavaScript running in a web page is subject to browser security restrictions. These restrictions prevent scripts from freely interacting with resources belonging to a different origin.
Because Selenium Core relied heavily on JavaScript running in the browser, the same-origin policy created limitations for browser automation.
Test Script
|
v
JavaScript
|
v
Browser Security Restrictions
|
v
Same-Origin Policy
|
v
Limited Cross-Origin Access
The Selenium developers needed a different architecture to work around these limitations.
Paul Hammant became interested in the Selenium project and discussions began about creating a driven mode in which Selenium could be controlled remotely through a programming language.
This approach introduced the idea of a server component between the test code and the browser.
Test Program
|
v
Selenium Client
|
v
Selenium Server
|
v
Web Browser
This architecture helped Selenium move beyond the limitations of running JavaScript directly inside the web page.
Selenium Core refers to the original JavaScript-based Selenium technology.
It was designed to execute browser automation instructions using JavaScript and interact directly with web page elements.
Test Instructions
|
v
Selenium Core
|
v
JavaScript Execution
|
v
Web Page
|
v
Browser
As Selenium evolved, the server-based approach became known as Selenium Remote Control, commonly called Selenium RC.
Selenium RC introduced a server component that acted as an intermediary between test code and the browser.
Test Script
|
v
Selenium Client Library
|
v
Selenium RC Server
|
v
Browser
|
v
Web Application
Selenium RC was an important milestone because it allowed test scripts to be written in programming languages and communicate with browsers through the Selenium server.
Selenium RC helped establish Selenium as a multi-language automation platform.
Client libraries were developed for different programming languages, allowing teams to write automation using languages familiar to their development or testing environments.
This language flexibility was one of the important reasons Selenium became popular among automation engineers.
Another major milestone in Selenium's history was the creation of Selenium IDE.
Shinya Kasatani in Japan developed an IDE module for Firefox that could record browser interactions and replay them as automated tests.
User Performs Action
|
v
Selenium IDE Records Action
|
v
Test Case Created
|
v
Test Case Replayed
|
v
Application Result
Selenium IDE was particularly useful for users who wanted to start browser automation without immediately writing large amounts of programming code.
Selenium IDE introduced a simple record-and-playback style of automation.
For example, a user could perform the following actions:
Selenium IDE could record these interactions and replay them later.
Record-and-playback helped demonstrate the concept of browser automation, but professional automation projects generally require maintainable test code, reusable components, synchronization, assertions, test frameworks, and structured automation architecture.
In 2007, Jason Huggins joined Google and became involved with Selenium development and support. Google also used Selenium for testing web applications.
Google's involvement helped demonstrate that Selenium could be used for large-scale web application testing.
As Selenium usage increased, another important requirement emerged: executing tests across multiple machines and browser environments.
In 2008, Philippe Hanrigou at ThoughtWorks developed Selenium Grid.
Selenium Grid enabled Selenium tests to be distributed across remote machines and browser environments.
100 Tests
|
v
One Machine
|
v
One Browser Environment
|
v
Long Execution Time
+--> Chrome Machine
|
Test Suite ------+--> Firefox Machine
|
+--> Edge Machine
|
+--> Other Environment
This architecture made large-scale and parallel test execution more practical.
Selenium Grid addressed the problem of running large numbers of tests across different environments.
While Selenium RC was being developed, Simon Stewart at ThoughtWorks was working on another browser automation project called WebDriver.
WebDriver followed a different architectural approach. Instead of depending primarily on JavaScript injection through a central server, WebDriver was designed to communicate with browsers through browser-specific automation mechanisms.
Test Code
|
v
WebDriver API
|
v
Browser Driver
|
v
Browser
|
v
Web Application
This architecture became the foundation for modern Selenium browser automation.
| Feature | Selenium RC | WebDriver |
|---|---|---|
| Architecture | Server-based | Browser-driver based |
| Communication | Uses Selenium server | Communicates through browser-specific driver mechanisms |
| JavaScript Dependency | Important part of the older architecture | Reduced dependence on injected page JavaScript |
| API | Older Selenium API | Higher-level WebDriver API |
| Modern Selenium | Legacy technology | Foundation of modern Selenium |
WebDriver was designed to address limitations associated with the older Selenium RC architecture.
The Selenium and WebDriver projects had overlapping goals but different architectural approaches.
Selenium RC had a large ecosystem and broad language support, while WebDriver offered a different and more direct approach to browser automation.
The projects eventually moved toward a merger, with WebDriver becoming the foundation of the next major Selenium generation.
Selenium Core
|
v
Selenium RC
|
+------------------+
|
v
Selenium 2
|
v
WebDriver
Selenium 2 represented the major transition toward WebDriver.
The Selenium project combined the Selenium and WebDriver technologies, with WebDriver becoming the primary browser automation API.
Selenium 2
|
+-- WebDriver
|
+-- Selenium RC Compatibility
|
+-- Selenium Grid
|
+-- Multiple Language Bindings
Over time, WebDriver became the dominant way of using Selenium for browser automation.
Modern Selenium usage is primarily centered around Selenium WebDriver.
WebDriver provides a common programming interface through which automation code can control supported browsers.
Java / Python / C# / JavaScript
|
v
Selenium API
|
v
Browser Driver
|
v
Browser
|
v
Web Application
Selenium 3 represented another major stage in Selenium's evolution. WebDriver had become the central browser automation approach, while Selenium RC was treated as legacy technology.
Selenium 3 continued the development of Selenium around WebDriver and modern browser automation.
When learning modern Selenium, students should focus primarily on WebDriver concepts rather than the older Selenium RC architecture.
Selenium 3 continued to strengthen the WebDriver-based approach.
Selenium 4 represents the modern generation of Selenium WebDriver.
Selenium 4 aligned WebDriver more closely with the W3C WebDriver standard, helping establish a standardized approach for browser automation.
Application
|
v
Automation Test
|
v
Selenium WebDriver
|
v
W3C WebDriver Protocol
|
v
Browser Driver
|
v
Browser
The W3C WebDriver standard defines a standardized protocol for controlling web browsers.
Selenium 4's architecture is aligned with the W3C WebDriver standard, making browser automation communication more standardized across supported browsers.
2004
JavaScriptTestRunner
|
v
Selenium Core
|
v
Selenium RC
|
+------------------+
| |
v v
Selenium IDE Selenium Grid
|
|
v
WebDriver
|
v
Selenium 2
|
v
Selenium 3
|
v
Selenium 4
|
v
Modern Web Automation
| Component | Historical Role | Modern Relevance |
|---|---|---|
| Selenium Core | Original JavaScript automation technology | Historical importance |
| Selenium RC | Server-based browser automation | Legacy |
| Selenium IDE | Record-and-playback browser automation | Useful for introductory automation and simple tests |
| Selenium Grid | Distributed browser execution | Important for parallel and remote execution |
| WebDriver | Browser automation API | Core modern Selenium technology |
| Person | Contribution |
|---|---|
| Jason Huggins | Created the original JavaScript-based Selenium automation technology. |
| Paul Gross | Contributed to the early Selenium project. |
| Jie Tina Wang | Contributed to early Selenium development. |
| Paul Hammant | Helped drive the development toward open source and the server-driven Selenium approach. |
| Dan Fabulich | Worked on the Selenium RC architecture. |
| Nelson Sproul | Worked on the Selenium RC server approach. |
| Pat Lightbody | Helped stabilize Selenium RC and worked on large-scale browser testing infrastructure. |
| Shinya Kasatani | Created Selenium IDE as a Firefox IDE module. |
| Simon Stewart | Created and developed WebDriver at ThoughtWorks. |
| Philippe Hanrigou | Created Selenium Grid. |
| Jennifer Bevan | Contributed to Selenium-related grid capabilities at Google. |
ThoughtWorks played a central role in the early history of Selenium.
The original Selenium project was created at ThoughtWorks in Chicago. Several important Selenium contributors were associated with ThoughtWorks during different stages of the project's development.
Google also played an important role in Selenium's development and adoption.
Google used Selenium for testing web applications and contributed engineering resources to the project.
Selenium became successful not only because of its original creators but also because of its open-source community.
Developers, testers, automation engineers, framework developers, organizations, and contributors helped extend the Selenium ecosystem.
The development of Selenium can be understood as part of the broader evolution from manual browser testing toward automated testing.
Manual Testing
|
v
Repetitive Browser Testing
|
v
JavaScriptTestRunner
|
v
Selenium Core
|
v
Selenium RC
|
v
WebDriver
|
v
Selenium 2
|
v
Selenium 3
|
v
Selenium 4
|
v
Modern Automation
Web applications became more complex over time. Browsers also introduced stronger security models, new standards, dynamic interfaces, JavaScript-heavy applications, and new browser automation capabilities.
Selenium therefore needed to evolve its architecture to support modern browser automation.
2004
Jason Huggins
|
v
JavaScriptTestRunner
|
v
Selenium Core
|
v
Selenium RC
|
+--------------------+
| |
v v
Selenium IDE Selenium Grid
|
|
v
WebDriver
|
v
Selenium + WebDriver
|
v
Selenium 2
|
v
Selenium 3
|
v
Selenium 4
|
v
W3C WebDriver
|
v
Modern Browser Automation
| Technology | Main Approach | Historical Importance |
|---|---|---|
| Selenium Core | JavaScript-based browser automation | Beginning of Selenium |
| Selenium RC | Server-based browser automation | Expanded language and browser automation capabilities |
| WebDriver | Browser-specific automation | Became the foundation of modern Selenium |
| Feature | Selenium IDE | Selenium WebDriver |
|---|---|---|
| Primary Approach | Record and playback | Programmatic automation |
| Programming Knowledge | Lower initial requirement | Programming knowledge is normally required |
| Complex Frameworks | Limited compared with code-based frameworks | Suitable for framework development |
| Page Object Model | Not the primary use | Commonly used |
| Data-Driven Testing | Limited compared with code-based automation | Widely used |
| CI/CD Automation | Less suited to complex automation pipelines | Commonly integrated with CI/CD |
Selenium Grid emerged because organizations needed to run browser tests across multiple machines and environments.
Instead of executing every test sequentially on one machine, Grid made distributed execution possible.
Test Suite
|
+---- Chrome / Windows
|
+---- Firefox / Windows
|
+---- Edge / Windows
|
+---- Chrome / Linux
|
+---- Firefox / macOS
This concept became especially important as organizations needed broad cross-browser and cross-platform coverage.
One of Selenium's important historical goals has been browser automation across different browser environments.
Modern Selenium WebDriver provides APIs that allow automation engineers to create tests that can be executed against supported browsers.
Selenium's evolution also included support for multiple programming languages.
This flexibility allowed organizations to integrate browser automation into different technology stacks.
Selenium itself provides browser automation capabilities, while professional teams commonly combine Selenium with testing frameworks and supporting tools.
Test Automation Framework
|
+-- Selenium WebDriver
|
+-- Test Framework
|
+-- Page Object Model
|
+-- Utilities
|
+-- Test Data
|
+-- Reports
|
+-- CI/CD
As software development moved toward Agile and DevOps practices, automated browser testing became useful for continuous integration and continuous testing.
Selenium tests can be integrated into automation pipelines so that browser tests are executed after application changes.
Developer
|
v
Code Commit
|
v
Build
|
v
Automated Tests
|
v
Selenium Tests
|
v
Test Results
|
v
Deployment Decision
Today, Selenium is primarily known for automated browser testing and browser automation using WebDriver.
It is commonly used for functional testing, regression testing, smoke testing, cross-browser testing, and end-to-end web application testing.
Requirement
|
v
Test Case
|
v
Automation Script
|
v
Selenium WebDriver
|
v
Browser
|
v
Web Application
|
v
Assertion
|
v
Test Report
Understanding Selenium history helps testers understand why modern Selenium uses WebDriver and why older technologies such as Selenium RC are considered legacy.
A beginner can remember the history of Selenium using the following simplified sequence:
2004
JavaScriptTestRunner
↓
Selenium Core
↓
Selenium RC
↓
Selenium IDE
↓
Selenium Grid
↓
WebDriver
↓
Selenium 2
↓
Selenium 3
↓
Selenium 4
↓
Modern Selenium
In an interview, you can explain the history of Selenium in a concise chronological manner.
Sample Answer:
Selenium started in 2004 at ThoughtWorks in Chicago when Jason Huggins created a JavaScript-based automation tool called JavaScriptTestRunner for testing an internal web application. It later evolved into Selenium Core and then Selenium Remote Control, or Selenium RC. Selenium IDE was created by Shinya Kasatani as a record-and-playback tool, while Selenium Grid was developed to support distributed and parallel browser execution. Simon Stewart developed WebDriver, which used a different browser automation architecture. Selenium and WebDriver eventually moved toward a combined project, leading to Selenium 2, followed by Selenium 3 and the modern Selenium 4 generation. Today, Selenium WebDriver is the central technology used for browser automation.
Selenium started in 2004 at ThoughtWorks in Chicago.
The original Selenium automation technology was created by Jason Huggins, with early contributions from colleagues including Paul Gross and Jie Tina Wang.
The original tool was called JavaScriptTestRunner.
Selenium Core was the early JavaScript-based browser automation technology that formed the foundation of later Selenium tools.
Selenium RC, or Selenium Remote Control, was an older server-based Selenium architecture that allowed test programs to communicate with browsers through a Selenium server.
Shinya Kasatani developed the Selenium IDE concept as a Firefox IDE module.
Simon Stewart developed WebDriver at ThoughtWorks.
Selenium Grid is designed for distributed browser execution, allowing Selenium tests to run across remote machines and browser environments.
WebDriver was developed as an alternative browser automation architecture that could communicate with browsers through browser-specific automation mechanisms rather than relying on the older Selenium RC approach.
Selenium 2 refers to the major Selenium generation built around the combination of Selenium and WebDriver, with WebDriver becoming the primary automation API.
Selenium 3 continued Selenium's WebDriver-focused evolution and treated Selenium RC as legacy technology.
Selenium 4 is the modern Selenium generation aligned with the W3C WebDriver standard.
| Term | Meaning |
|---|---|
| JavaScriptTestRunner | Original browser automation tool created by Jason Huggins. |
| Selenium Core | Early JavaScript-based Selenium automation technology. |
| Selenium RC | Older server-based Selenium Remote Control architecture. |
| Selenium IDE | Record-and-playback Selenium tool originally created as a Firefox IDE module. |
| Selenium Grid | Distributed execution technology for running tests across environments. |
| WebDriver | Modern browser automation API and foundation of Selenium. |
| Selenium 2 | Selenium generation centered around WebDriver. |
| Selenium 3 | WebDriver-focused Selenium generation following the transition away from RC. |
| Selenium 4 | Modern Selenium generation aligned with W3C WebDriver. |
Selenium
|
+-- 2004
| |
| +-- Jason Huggins
| +-- ThoughtWorks
| +-- JavaScriptTestRunner
|
+-- Selenium Core
| |
| +-- JavaScript Automation
| +-- Web Page Interaction
|
+-- Selenium RC
| |
| +-- Selenium Server
| +-- Client Libraries
| +-- Multi-language Support
|
+-- Selenium IDE
| |
| +-- Shinya Kasatani
| +-- Record
| +-- Playback
|
+-- Selenium Grid
| |
| +-- Distributed Execution
| +-- Remote Machines
| +-- Parallel Testing
|
+-- WebDriver
| |
| +-- Simon Stewart
| +-- Browser Automation
| +-- Browser Drivers
|
+-- Selenium 2
| |
| +-- WebDriver
| +-- Grid
|
+-- Selenium 3
| |
| +-- WebDriver Focus
|
+-- Selenium 4
|
+-- W3C WebDriver
+-- Modern Browser Automation
| Area | Older Selenium | Modern Selenium |
|---|---|---|
| Core Technology | Selenium Core / RC | WebDriver |
| Communication | Server and JavaScript-based approaches | WebDriver-based browser communication |
| Browser Driver | Not based on the modern driver model | Browser-specific drivers are used |
| Standardization | Older Selenium protocols | W3C WebDriver standard |
| Framework Usage | Older testing approaches | Modern automation frameworks |
Automation Engineer
|
v
Programming Language
|
v
Selenium WebDriver API
|
v
Browser Driver
|
v
Browser
|
v
Web Application
|
v
Test Result
This flow represents the modern Selenium WebDriver approach and is very different from the original JavaScriptTestRunner architecture.
Suppose a company wants to test an online shopping website.
Tester
|
+-- Open Browser
+-- Open Website
+-- Login
+-- Search Product
+-- Add Product
+-- Checkout
+-- Verify Result
The tester has to repeat these actions whenever the application changes.
Automation Script
|
v
Selenium WebDriver
|
v
Browser
|
v
Shopping Website
|
v
Automated Validation
|
v
Test Report
This evolution explains why Selenium became an important technology for web application test automation.
As web applications became larger, testing previously implemented functionality after every software change became increasingly important.
Selenium provides browser automation capabilities that can be used to automate regression test scenarios.
New Feature Added
|
v
Application Build
|
v
Regression Test Suite
|
v
Selenium WebDriver
|
v
Browser Automation
|
v
Regression Results
Selenium's development took place in an environment where Agile software development practices were important at ThoughtWorks.
Automated testing supports the idea of repeatedly testing software as changes are introduced.
Sprint
|
v
Development
|
v
Build
|
v
Automated Tests
|
v
Selenium Tests
|
v
Feedback
|
v
Fix / Improve
Modern Selenium automation can be incorporated into DevOps workflows and continuous testing pipelines.
Developer
|
v
Git Commit
|
v
CI Server
|
v
Build
|
v
Unit Tests
|
v
Selenium Tests
|
v
Reports
|
v
Deployment
The history of Selenium demonstrates a gradual movement from a simple browser scripting tool toward a standardized browser automation platform.
Simple Automation
|
v
Reusable Automation
|
v
Remote Automation
|
v
Record and Playback
|
v
Distributed Testing
|
v
Browser-Specific Automation
|
v
WebDriver
|
v
Standardized Browser Automation
Jason Huggins created the original Selenium automation technology while working at ThoughtWorks.
The Selenium story began in 2004.
The project began at ThoughtWorks in Chicago.
The original tool was called JavaScriptTestRunner.
It automated repetitive browser-based testing of web applications.
Selenium Core was the early JavaScript-based Selenium automation technology.
RC means Remote Control.
Selenium RC was an older server-based Selenium automation architecture.
Shinya Kasatani created Selenium IDE as a Firefox-based IDE module.
Simon Stewart developed WebDriver at ThoughtWorks.
WebDriver provided a different browser automation architecture that addressed limitations of the older Selenium RC approach.
Selenium Grid supports distributed browser execution across remote machines and environments.
Selenium 2 represents the Selenium generation centered around WebDriver.
Selenium 3 continued the WebDriver-based evolution of Selenium.
Selenium 4 is the modern Selenium generation aligned with the W3C WebDriver standard.
Your interviewer asks: "Explain the complete history of Selenium from its beginning to Selenium 4."
2004
↓
JavaScriptTestRunner
↓
Selenium Core
↓
Selenium RC
↓
Selenium IDE
↓
Selenium Grid
↓
WebDriver
↓
Selenium 2
↓
Selenium 3
↓
Selenium 4
↓
W3C WebDriver
A good answer should explain the purpose of each stage instead of simply memorizing version numbers.
| Question | Answer |
|---|---|
| Started | 2004 |
| Original Creator | Jason Huggins |
| Company | ThoughtWorks |
| Location | Chicago |
| Original Name | JavaScriptTestRunner |
| Early Technology | JavaScript-based automation |
| Remote Technology | Selenium RC |
| Record-and-Playback Tool | Selenium IDE |
| Distributed Testing | Selenium Grid |
| Modern Automation API | Selenium WebDriver |
| Modern Standard | W3C WebDriver |
Selenium began in 2004 at ThoughtWorks when Jason Huggins created JavaScriptTestRunner to automate repetitive testing of an internal web application. The technology evolved into Selenium Core and later Selenium Remote Control. Selenium IDE was created by Shinya Kasatani as a record-and-playback tool, while Selenium Grid was developed for distributed browser testing. Simon Stewart developed WebDriver as a different browser automation architecture. Selenium and WebDriver eventually came together in the Selenium project, leading to Selenium 2. Selenium 3 continued the WebDriver-focused approach, and Selenium 4 became the modern generation aligned with the W3C WebDriver standard.
2004
Jason Huggins
↓
JavaScriptTestRunner
↓
Selenium Core
↓
Selenium RC
↓
Selenium IDE
↓
Selenium Grid
↓
WebDriver
↓
Selenium 2
↓
Selenium 3
↓
Selenium 4
↓
W3C WebDriver
After studying the history of Selenium, learners should be able to:
| Stage | Technology | Main Purpose |
|---|---|---|
| 1 | JavaScriptTestRunner | Automate repetitive browser testing. |
| 2 | Selenium Core | JavaScript-based web browser automation. |
| 3 | Selenium RC | Remote/server-based browser automation. |
| 4 | Selenium IDE | Record and replay browser interactions. |
| 5 | Selenium Grid | Distributed and parallel browser execution. |
| 6 | WebDriver | Modern browser automation API. |
| 7 | Selenium 2 | WebDriver-centered Selenium generation. |
| 8 | Selenium 3 | Continued WebDriver-focused development. |
| 9 | Selenium 4 | Modern W3C WebDriver-based Selenium. |
If you want to learn Selenium from fundamentals to professional automation concepts, you can explore the JustAcademy Selenium Training.
You can also use the JustAcademy Selenium Course Demo Registration link to register for a course demo.
The history of Selenium is a story of continuous improvement in web browser automation. It started in 2004 at ThoughtWorks with Jason Huggins' JavaScriptTestRunner, created to automate repetitive testing of an internal web application. The project evolved into Selenium Core and then Selenium RC, which introduced a server-based approach to browser automation. Selenium IDE brought record-and-playback capabilities, while Selenium Grid addressed distributed browser execution.
WebDriver introduced a different and more direct browser automation architecture and eventually became the foundation of modern Selenium. Selenium 2 marked the major transition toward WebDriver, Selenium 3 continued the WebDriver-focused evolution, and Selenium 4 brought Selenium into its modern W3C WebDriver-aligned era.
Understanding this history makes it easier to understand why modern Selenium uses WebDriver, browser drivers, Selenium Grid, programming language bindings, testing frameworks, and standardized browser automation protocols.
2004
|
v
JavaScriptTestRunner
|
v
Selenium Core
|
v
Selenium RC
|
+------------------+
| |
v v
Selenium IDE Selenium Grid
|
|
v
WebDriver
|
v
Selenium 2
|
v
Selenium 3
|
v
Selenium 4
|
v
W3C WebDriver
|
v
Modern Web Browser Automation
For additional historical information, learners can refer to the official Selenium History page and the official Selenium About page.
